Given the continually increased reliance on computers in contemporary society, computer technology has had to advance on many fronts to keep up with increased demand. One particular subject of significant research and development efforts is parallelism, i.e., the performance of multiple tasks in parallel.
A number of computer software and hardware technologies have been developed to facilitate increased parallel processing. From a software standpoint, multithreaded operating systems and kernels have been developed, which permit computer programs to concurrently execute in multiple “threads” so that multiple tasks can essentially be performed at the same time. Threads generally represent independent paths of execution for a program. For example, for an e-commerce computer application, different threads might be assigned to different customers so that each customer's specific e-commerce transaction is handled in a separate thread.
From a hardware standpoint, computers increasingly rely on multiple microprocessors to provide increased workload capacity. Furthermore, some microprocessors have been developed that support the ability to execute multiple threads in parallel, effectively providing many of the same performance gains attainable through the use of multiple microprocessors.
One logical extension of parallel processing is the concept of logical partitioning, where a single physical computer is permitted to operate essentially like multiple and independent “virtual” computers (referred to as logical partitions), with the various resources in the physical computer (e.g., processors, memory, input/output devices) allocated among the various logical partitions. Each logical partition executes a separate operating system, and from the perspective of users and of the software applications executing on the logical partition, operates as a fully independent computer.
With logical partitioning, a shared program, often referred to as a “hypervisor” or partition manager, manages the logical partitions and facilitates the allocation of resources to different logical partitions. For example, a partition manager may allocate resources such as processors, workstation adapters, storage devices, memory space, network adapters, etc. to various partitions to support the relatively independent operation of each logical partition in much the same manner as a separate physical computer.
In connection with managing logical partitions, it may be desirable for individual partitions to be able to manage and interact with the various resources allocated to those partitions. To enable such management functionality, a partition manager often supports an interface through which a partition can request performance of certain partition management operations by the partition manager. Given, however, that each partition executes in a separate memory space from a partition manager, the communication between a partition and partition manager must follow a regimented protocol that maintains the barriers put in place between the partition and the partition manager.
Different types of partition management operations, however, may require different actions to be undertaken by a partition manager. Furthermore, these actions may require different degrees of effort on the part of the partition manager. Some partition management operations, for example, may be processed immediately, and may not require a partition to wait to be advised of whether a particular operation has been completed. Other partition management operations, on the other hand, may require substantial effort on the part of the partition manager, and may require access to various hardware devices in a computer, which can require a substantial amount of time to complete. In these latter instances, it may be inefficient to require a partition to wait for the partition manager to complete the operation and notify the partition that the operation has been completed.
For example, one type of partition management operation that may be initiated by a partition is a resource state change operation. In particular, resources in a logically-partitioned computer, e.g., processors, memory, input/output devices, storage devices, display devices, communication devices, and adapters therefor (whether real or virtual), are typically represented by objects in the memory space of a partition manager. The objects are capable of interacting with the actual devices to perform certain management operations on the devices. Moreover, the objects typically store state information about their associated devices, and as certain resources are allocated to particular partitions, the objects representing those resources are updated to reflect such ownership.
A partition that uses a particular resource managed by a partition manager may have the ability to update the state of that resource through a partition management operation. For example, it may be desirable for a partition to be able to power a resource on or off, to enable or disable access to the resource, or to release the resource for use by other partitions. However, depending on the particular type of resource that is being updated, the amount of time and processing overhead actually required to effect the state change may vary substantially. As a result, it has been difficult to provide a common interface between a partition and a partition manager that is capable of efficiently handling state change operations for different types of resources.
One possible type of interface that might be implemented to enable a partition to initiate a state change with a partition manager is a purely event-driven interface, whereby a partition sends an event to a partition manager to request the state change, and then waits for a return event from the partition manager when the operation is complete. One disadvantage of such an interface is that the partition is typically always forced to wait for the return event, even when the object is already in the requested state, or when the object can immediately be updated to the requested state, which can result in added response time and increased system overhead. In addition, correlation of a return event with the request event may be problematic in some implementations.
Another type of interface that might be implemented to enable a partition to initiate a state change with a partition manager is to provide a call-based interface where a partition calls the partition manager and obtains a return code therefrom indicating that the requested state change is in progress. Subsequent calls may be made until a success return code is returned once the requested state change completes. One disadvantage of such an interface is that a partition is typically required to spin or busy wait for the state change to occur, again tying up system resources, and decreasing system throughput.
It is believed that a root problem associated with the aforementioned interface implementations results directly from the significantly different response times and system overhead that may be experienced when performing the same type of partition management operation for different types of resources, and in different sets of circumstances. While certain interface types may provide optimal results for some types of resources, those same interface types may provide suboptimal results for others.
Therefore, a substantial need has arisen for a more flexible and efficient manner of handling partition management operations in a logically-partitioned computer, particularly to address the different circumstances that may arise for operations performed on different types of resources that may reside in a logically-partitioned computer.